The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided in this application is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Web browsers are built on top of HTTP, which is a stateless request/response protocol initially designed for serving static web pages. HTTP is built on top of TCP, a low-level protocol which guarantees data sent over the internet arrives reliably, and in the same order it was sent.
TCP is a reliable-ordered protocol, which means packets of data must be interpreted in the correct order. To deliver data reliably (and in order) while experiencing packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order. This is called “head of line blocking,” and it creates problems for game developers who send time-series data such as player inputs and the state of objects in a game world. When time series data is sent over TCP, the most recent data is delayed while waiting for old data to be retransmitted. By the time the retransmitted data arrives, it is too old to be used.
HTTP has functioned well for many years, but recently websites have become more interactive and poorly suited to the HTTP request/response paradigm. Some have attempted to address these shortcomings with modern web protocols like WebSockets (a computer communications protocol that provides full-duplex communication channels over a single TCP connection), WebRTC (a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple JavaScript APIs), HTTP 2.0 (an improved HTTP protocol designed to decrease latency to improve page load speed in web browsers), and QUIC (a protocol similar to TCP+TLS+HTTP/2 except it is implemented on UDP).
WebSockets are an extension to the HTTP protocol, which enables bidirectional data exchange—an improvement over the traditional request/response pattern. Although bidirectional data exchange is a step in the right direction, WebSockets are implemented on top of TCP, and data is still subject to head of line blocking.
QUIC is an experimental protocol that supports multiple data streams, and it is built on top of UDP. QUIC is designed as replacement transport layer for HTTP. New data streams can be created implicitly by the client or server by increasing the channel ID. The channel concept implemented by QUIC has two key benefits: it avoids a connection handshake each time a new request is made, and it eliminates head of line blocking between unrelated data streams. But while head of line blocking is eliminated across unrelated data streams, it persists within each individual stream.
WebRTC is a collection of protocols that enable peer-to-peer communication between browsers for applications like audio and video streaming. WebRTC supports a data channel that can be configured in unreliable mode, providing a way to send and receive unreliable-unordered data from the browser. WebRTC includes STUN, ICE, and TURN support. STUN, ICE, and TURN are IETF standard protocols for negotiating traversing NATs when establishing peer-to-peer communication sessions. But within the game development community, there exists a trend away from peer-to-peer communication towards client/server communication for multiplayer games, and while WebRTC supports unreliable-unordered peer-to-peer data exchanged between browsers, it is difficult to use WebRTC in a client/server context.
Another solution to consider is to allow users send and receive UDP packets directly from the browser. This fails for several reasons. (1) Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers. (2) New security holes would be created as JavaScript running in web pages could craft malicious UDP packets to probe the internals of corporate networks and report back over HTTPS. (3) UDP packets are not encrypted, so any data sent over these packets could be sniffed and read by an attacker, or even modified during transmission. And (4), there is no authentication, so a dedicated server reading packets sent from a browser would have to implement its own method to ensure that only valid clients can connect to it. Therefore, allowing JavaScript to create UDP sockets in the browser is a nonstarter.
At worst these new standards for web development do not provide adequate technological infrastructure to meet multiplayer game's needs, and, at best, they provide it in a form that is too complicated for game developers to use. Thus, there is still a need for a protocol that implements the ability to send and receive UDP packets in the browser.
These and all other extrinsic materials discussed in this application are incorporated by reference in their entirety. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided in this application, the definition of that term provided in this application applies and the definition of that term in the reference does not apply.